『Clean Architecture』
https://gyazo.com/c21fc687464d898b04b946a928247cc0
第I部 イントロダクション
1章
「設計」と「アーキテクチャ」に違いはない
ソフトウェアアーキテクチャの目的は、システムの構築、保守をするための人数を減らすこと
良いアーキテクチャだと
システムの構築、保守をするために必要な人数を減らすことができる
悪いアーキテクチャだと
リリースごとに労力は増える
第1章 設計とアーキテクチャ
目的は？
ケーススタディ
まとめ
2章
ソフトウェアはステークホルダーに「振る舞い」と「構造」という2つの価値を提供する
振る舞い
ソフトウェアの振る舞いをコードで表現する
構造
ソフトウェアはソフトでないといけない
変更の難易度は、変更の形状ではなく、変更のスコープに比例するようにする
ステークホルダーはジグゾーパズルのピースを後から後から渡してくる
ビジネスマネージャーはアーキテクチャの重要性を評価できない
そのためにソフトウェア開発者が雇われている
機能の緊急性よりもアーキテクチャの重要性をを主張する責任がある
第2章 2つの価値のお話
振る舞い
アーキテクチャ
大きな価値
アイゼンハワーのマトリックス
アーキテクチャの戦い
第II部 構成要素から始めよ
第3章 パラダイムの概要
構造化プログラミング
オブジェクト指向プログラミング
関数型プログラミング
考えるべきこと
まとめ
第4章 構造化プログラミング
証明
有害宣言
機能分割
正式に証明できない
救済のための科学
テスト
まとめ
第5章 オブジェクト指向プログラミング
カプセル化とは？
継承とは？
ポリモーフィズムとは？
まとめ
第6章 関数型プログラミング
整数の二乗
不変性とアーキテクチャ
可変性の分離
イベントソーシング
まとめ
第III部 設計の原則
第III部 設計の原則
7章
最初のページで「この法則が誤解される原因は名前があまり良くなかったことだ」と言っている
よくなさすぎるmrsekut.icon
症例1の理由、微妙なじゃないか？
Employeeクラスが複数責任を持っていること、regularHoursの修正によってreportHoursがバグったことに直接的な関係があるのか？
regularHoursの仕様変更によってこれが修正されたのであれば、これの存在理由が変わっている
だから本来なら、
regularHoursではない、新たな関数を作る
regularHoursの内部を修正するなら、これを使っている関数を全箇所直す
さらに関数名も変える
etc.
のいずれかをすべき、という話であって、単一責任云々の問題なのか？
症例2の理由も、微妙な気がする
クラス単位の単一責任の話、と完全に前提しているならわかる
これがもし、「単一責任のUtility関数」の1つだとしても同じ問題が生じる
2チームが全く同じ様に修正すべきという話ではある。
これが悪いなら、「チームで完全に別のコードベース使えや」という話になってしまう
名前がおかしいなら話は別mrsekut.icon
8
第8章 OCP：オープン・クローズドの原則
思考実験
方向の制御
情報隠蔽
まとめ
第9章
第10章 ISP：インターフェイス分離の原則
インターフェイス分離の原則（ISP）と言語との関係
インターフェイス分離の原則（ISP）とアーキテクチャとの関係
まとめ
11章
第IV部 コンポーネントの原則
どういうまとまりを1つのComponentとみなすか？
どのclassを、どのComponentに含めるべきか？
第V部 アーキテクチャ
15章
良いアーキテクチャとは、良い設計とは、の抽象的な話
16章
もうちょい具体化すれば、Componentごと、Deploy単位ごと、実行単位(Service)ごとに独立させられるということ
17章
タイトルの「境界線を引く」って、最近(2023/9)考えてる「分節」とかなり近いものな気がするmrsekut.icon
いやちょっとちゃうなmrsekut.icon
境界というのはその名の通り境界で、概念と概念の間の線の着目や
第18章 境界の解剖学
境界を超えることと、依存関係
「上位」とか「下位」とかの言い方がわかりにくいmrsekut.icon
上位がEntityのような軸に近い方mrsekut.icon
IOがあるものは最下位になる
第19章 方針とレベル
4ページぐらいしか無い
「レベル」の厳密な定義は「入力と出力からの距離」である。
抽象度の指標という感じか
たしかにそういう表現もできるだろうが、
が、「レベル」とか「距離」とか言う用語を導入する有用性が低いように感じるmrsekut.icon
もっと良い表現があると思う
「距離」で他のものと比較しづらい
同じ対象との相対でしか比較できない
未だに「Policy」という単語をどういう意味で使ってるのかよくわからないなぁmrsekut.icon 第20章 ビジネスルール
初見では絶対理解できないであろうEntityの説明がある
最重要ビジネスルールと最重要ビジネスデータは密接に結び付いているため、オブジェクトの有力な候補になる。こうしたオブジェクトのことをエンティティと呼びたい。
常に「⇔」が成り立つわけ無いので、正確な表現ではないだろうmrsekut.icon
第22章 クリーンアーキテクチャ
第23章 プレゼンターとHumble Object
プレゼンターとビュー
テストとアーキテクチャ
データベースゲートウェイ
データマッパー
サービスリスナー
まとめ
第24章 部分的な境界
最初、何を言ってるのか分からなかったが、この画像見たら即座にわかった
https://gyazo.com/84ef3a1195d6206bcf626449192ba78c https://twitter.com/syobochim/status/1525431520076234752
ちゃんと境界のコストについて書かれてるじゃないかmrsekut.icon
CA本を読んだ人に「全部にInterfaceを定義してimplementsするぞ！」としてる人が多い印象があった
最後のステップを省略する
片方だけの境界
Facade
まとめ
第25章 レイヤーと境界
まとめとして良い章だったmrsekut.icon
第26章 メインコンポーネント
Main Componentは究極的な詳細
第27章 サービス：あらゆる存在
サービスアーキテクチャ？
サービスのメリット？
子猫の問題
救世主のオブジェクト
コンポーネントベースのサービス
横断的関心事
まとめ
第28章 テスト境界
普通に良かったmrsekut.icon
CAの考え方の延長線上にtestを置く
システムコンポーネントとしてのテスト
テスト容易性のための設計
テストAPI
まとめ
第29章 クリーン組込みアーキテクチャ
適性テスト
ターゲットハードウェアのボトルネック
まとめ
第VI部 詳細
第30章 データベースは詳細
(データモデルではなく)データベースは詳細
どんなデータストアであったとしても、RAMに読み込んで、リスト、セット、スタック、キュー、ツリーなどの使いやすい構造にして使っているはず
第31章 ウェブは詳細
GUIは詳細、切り離そう
第32章 フレームワークは詳細
フレームワークと結合しないように注意する
第33章 事例：動画販売サイト
プロダクト
ユースケース分析
コンポーネントアーキテクチャ
依存性管理
まとめ
第VII部 付録
付録A アーキテクチャ考古学
組合の会計システム
レーザーカット
アルミダイキャストの監視
4-Tel
サービスエリアコンピュータ
C言語
BOSS
pCCU
DLU/DRU
VRS
電子受付
転送システムの作成
明確なコミュニケーション
ROSE
アーキテクト登録試験
まとめ